寫在前面：
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA，歐盟網路韌性法）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、產品資安（Product Security）的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、歐盟執委會（European Commission）後續指引（Guidance）、協調標準（Harmonised Standards）及主管機關實務為準。
歐盟執委會已於 2026 年 7 月 27 日發布第一批 CRA Guidance，其中就特別針對**重大修改（Substantial Modification）**提供進一步說明。這份 Guidance 本身並不具法律拘束力（Non-binding），但對目前正在準備 CRA 的企業而言，我覺得仍然很有參考價值。

CE 貼上去之後，產品就不能改了嗎？
Day 16 談到一條很重要的流程：
符合性評估（Conformity Assessment）
→ EU 符合性聲明（EU Declaration of Conformity）
→ CE 標示（CE Marking）
做到這裡，看起來產品終於可以上市了。
但真正的產品生命週期（Product Lifecycle）當然不會停在上市的那一天。產品上市後，還可能有韌體更新（Firmware Update）、軟體升級（Software Upgrade）、元件更換（Component Replacement）、新增功能（New Feature）、硬體改版（Hardware Revision）、錯誤修正（Bug Fix），甚至安全修補（Security Patch）。
所以我開始想到一個很實際的問題：
產品改了之後，原本做過的 CRA 符合性評估還能不能繼續沿用？
這就帶到今天的主題：CRA 的 重大修改（Substantial Modification）。

一、什麼叫重大修改（Substantial Modification）？
CRA Article 3 對 Substantial Modification 有正式定義。
如果先不用法規語言，我自己會把它理解成：具有數位元素的產品（Product with Digital Elements）上市之後，如果發生的變更會影響產品符合 CRA 基本資安要求（Essential Cybersecurity Requirements）的能力，或改變製造商（Manufacturer）原先進行資安風險評估（Cybersecurity Risk Assessment）時所依據的預期用途（Intended Purpose），就可能需要進一步討論這項修改是否構成 Substantial Modification。
所以我現在遇到產品改版時，不太會先問：
「改了多少 Code？」
我反而會先問：
「到底改了什麼？這項變更對產品資安風險，以及原本的符合性基礎（Conformity Basis）造成什麼影響？」
我覺得這兩個問題，比單純看版本號（Version Number）或程式碼變更量（Code Change Size）更重要。

二、所以不是「只要改版就要重新做 CE」
這一點我覺得要先釐清。
如果每一次 Software Update 都要完整重新做一次 CRA Conformity Assessment，對持續更新的 Software Product 來說，實務上可能很難運作。
CRA Recital 39 就提供了一些很實際的例子。例如安全更新（Security Update）的目的如果是降低資安風險（Cybersecurity Risk），而且沒有改變產品的 Intended Purpose，原則上不會單純因為這樣就被視為 Substantial Modification。
這對我來說其實滿合理的。
因為 CRA 本來就要求 Manufacturer 在支援期間（Support Period）持續處理漏洞（Vulnerability）。如果每修補一個 Vulnerability，就自動觸發完整的重新符合性評估，反而可能讓 Security Update 變得更困難。
所以「產品有改版」跟「產品發生 Substantial Modification」，其實不能直接畫上等號。

三、Security Patch 通常不是，但我不會只看 Release 名稱
例如今天發現一個身分驗證漏洞（Authentication Vulnerability），Manufacturer 修改程式碼，修正 Authentication Validation。
如果這個 Update 的目的就是降低既有的 Cybersecurity Risk，而且沒有改變 Intended Purpose，依 CRA Recital 39 的說明，一般不會單純因此構成 Substantial Modification。
但我自己還是會避免訂出一條過度簡化的規則：
「只要 Release Note 寫 Security Patch，就一定不是 Substantial Modification。」
因為真正應該看的，還是修改的實質內容。
一個 Release 可以同時包含安全修正（Security Fix）與新增功能（New Feature），所以名稱到底叫 Patch、Hotfix、Minor Release 還是 Major Release，我覺得都不是最核心的判斷依據。
真正重要的，還是這個 Change 到底改變了什麼。

四、小型功能調整，通常也不用太緊張
CRA Recital 39 還舉了一些很生活化的例子。
例如視覺效果改善（Visual Enhancement）、新增圖示（Pictogram），或增加使用者介面語言（UI Language），這類小型功能更新（Minor Functionality Update），一般不應被視為 Substantial Modification。
所以產品每次 UI 改版，並不代表 CRA Conformity 就要全部重新來一次。
這讓我越來越覺得，判斷 Substantial Modification 真正要看的不是：
「產品有沒有 Change？」
而是：
「這項變更有沒有實質影響原本的資安假設（Cybersecurity Assumptions）？」
這兩個問題看起來很像，但實務上的差異其實非常大。

五、真正要特別注意的，可能是「新增功能」
假設原本產品只有本地介面（Local Interface），新版突然新增了遠端網路存取（Remote Network Access）；或者原本不接受外部輸入（External Input），新版新增了一個輸入介面（Input Interface）。
這時候產品的**攻擊面（Attack Surface）**就可能跟著改變。
CRA Recital 39 特別提到，如果功能更新（Feature Update）改變原本的預期功能（Intended Functions）、類型（Type）或效能（Performance），並符合相關條件，就可能構成 Substantial Modification。
法規甚至舉了新增 Input Element 的例子，因為新的輸入可能需要新的輸入驗證（Input Validation），也可能因此擴大 Attack Surface。
看到這裡，我自己反而覺得 Substantial Modification 的概念跟：
變更風險評估（Change Risk Assessment）
非常接近。
重點並不是「有沒有改」，而是「改了之後，原本的風險假設還成不成立」。

六、先問三個問題
如果產品發生 Change，我自己可能會先從三個方向進行第一層判斷。
第一個問題是：**預期用途（Intended Purpose）有沒有改變？**例如原本只提供儲存功能（Storage Function），現在卻新增安全身分驗證功能（Security Authentication Function）。
第二個問題是：**資安危害（Cybersecurity Hazard）的性質有沒有改變？**例如原本完全沒有網路曝險（Network Exposure），新版卻開始支援遠端存取（Remote Access）。
第三個問題則是：**資安風險等級（Cybersecurity Risk Level）有沒有增加？**例如新增外部介面（External Interface），因而帶來新的 Attack Surface。
如果這三個方向都沒有明顯變化，我可能會比較傾向先判斷為非重大修改（Not Substantial）；如果其中任何一項有明顯變化，就進一步進行詳細評估（Detailed Assessment）。
這當然不是 CRA 官方規定的三題 Checklist，只是我自己目前覺得很適合放進產品變更審查（Change Review）的第一層篩選（Screening）。

七、原始 Risk Assessment 在這裡突然變得很重要
這也是我研究到這裡很有感的一點。
CRA Recital 39 特別把**初始風險評估（Initial Risk Assessment）**拉進 Substantial Modification 的判斷。
例如某個 Product Roadmap 本來就規劃未來增加某項功能，而且 Manufacturer 在最初的 Cybersecurity Risk Assessment 中已經合理預見並評估這項 Change，這跟原本完全沒有預期、後來突然加入的重大功能變更，情境就可能不太一樣。
所以 Day 6 談過的 Risk Assessment，到了 Day 17 又回來了。
這也讓我開始覺得，產品資安風險評估（Product Risk Assessment）最好不要只描述 Release 1.0 今天長什麼樣子。
如果公司已經知道產品未來有規劃中的功能（Planned Functions）或預期演進（Expected Evolution），適度納入 Risk Consideration，可能對後續的 Change Assessment 很有幫助。
這也再次讓我感受到，CRA 裡很多工作其實不是彼此獨立的。前面的 Risk Assessment 做得好不好，可能一路影響後面的 Change Management 與 Conformity Assessment。

八、Hardware Change 當然也可能進來
Substantial Modification 並不只發生在 Software。
對 Semiconductor Company 來說，我反而覺得**硬體變更（Hardware Change）**很值得注意，例如 Hardware Revision、Component Replacement、Interface Change、Embedded Firmware Change，甚至 Security IP Replacement。
假設原本使用 Security Component A，後來改成 Component B，如果因此改變資安架構（Security Architecture）、密碼能力（Cryptographic Capability）、Attack Surface 或威脅曝險（Threat Exposure），我自己就會重新檢視 Cybersecurity Risk Assessment 與 Annex I Conformity。
所以做到這裡，我開始覺得：
企業既有的工程變更（Engineering Change）、產品變更通知（Product Change Notice，PCN）或產品改版（Product Revision）流程，可能就是 CRA 最適合整合進去的地方。
不一定需要為了 CRA，再重新創造一套完全獨立的 CRA Change Management System。

九、一般 Repair / Maintenance 不一定算重大修改
這一點也很重要。
CRA Recital 42 說明，翻新（Refurbishment）、維護（Maintenance）與維修（Repair）並不必然構成 Substantial Modification。
例如產品的 Intended Purpose 與 Functionality 都沒有改變，而且 Cybersecurity Risk Level 也沒有受到影響，就不一定因為產品被修過、某個零件被換過，就構成重大修改。
所以我自己會避免看到：
「Hardware 被換過。」
就直接下結論：
「Substantial Modification。」
還是要回到最核心的問題：
這項變更的影響（Change Impact）到底是什麼？
這也是為什麼我覺得 Change Assessment 比單純的 Change Classification 更重要。

十、如果真的構成 Substantial Modification，會發生什麼？
這就是最重要的一段。
CRA Recital 41 說明，如果發生可能影響 CRA Conformity 的 Substantial Modification，或者產品的 Intended Purpose 發生改變，就應重新確認產品符合性，並在適用情況下進行新的符合性評估（New Conformity Assessment）。
所以 Substantial Modification 不是單純在 Change Request 裡面多打一個勾。
它可能一路帶動：
資安風險評估更新（Cybersecurity Risk Assessment Update）
→ Annex I 重新評估（Annex I Reassessment）
→ 技術文件更新（Technical Documentation Update）
→ 資安驗證（Security Verification）
→ 符合性重新評估（Conformity Reassessment）
至於最後是否需要做到完整的 New Conformity Assessment，還是要依實際 Change、影響程度與原本適用的 Conformity Assessment Route 進一步判斷。

十一、那原本 CE 是不是「失效」？
這題我自己會避免直接使用：
「CE 失效。」
我比較會說：
「原本的符合性基礎（Conformity Basis）是否仍然足以涵蓋修改後的產品，需要重新確認。」
因為真正的問題並不是產品上面的兩個字母還在不在，而是原本支撐 CE 的那些東西，例如 Risk Assessment、Annex I Mapping、Security Design、Testing、Technical Documentation 與 Conformity Assessment，對修改後的產品是否仍然成立。
所以我現在會把問題從：
「原本的 CE 還算不算數？」
改成：
「CE 背後的 Conformity Basis 還成立嗎？」
我覺得這樣比較容易抓到 CRA 真正關心的問題。

十二、如果原本有第三方參與，也可能需要通知
如果產品原本採用涉及**第三方（Third Party）**的 Conformity Assessment Route，Change Management 還可能需要再多一個動作。
CRA Recital 41 提到，如果 Manufacturer 採用涉及 Third Party 的符合性評估，對於可能導致 Substantial Modification 的 Change，在適用情況下應通知相關 Third Party。
所以對需要公告機構（Notified Body，NB）參與的產品，我自己會希望在 Change Process 裡面增加一個判斷：
「這項變更是否需要通知符合性評估機構（Conformity Assessment Body）？」
這件事情如果等產品全部改完、準備 Release 了才想到，實務上可能就比較麻煩。
所以如果一開始就知道某類產品採取的是 Third-party Conformity Assessment，相關通知機制最好也一起放進 Change Management。

十三、比較有意思的是，修改產品的不一定是原 Manufacturer
CRA Article 22 我覺得非常值得注意。
假設某個自然人或法人並不是原始製造商（Original Manufacturer）、進口商（Importer）或經銷商（Distributor），但他對產品做了 Substantial Modification，之後又把修改後的產品提供於市場（Made Available on the Market），CRA 可能會把這個人或實體視為 Manufacturer。
Article 22 還進一步規定，該 Person / Entity 對於受到 Substantial Modification 影響的產品部分，需要承擔 Article 13 與 Article 14 的相關 Manufacturer Obligations；如果 Modification 影響到整個產品的 Cybersecurity，責任範圍也可能進一步擴及整個產品。
這對我來說是一個滿重要的觀念。
Manufacturer 不完全只是「最初把 Hardware 做出來的人」。
後續到底是誰做了什麼 Modification，以及修改後的 Product 又如何進入市場，也可能改變 CRA 下的責任角色。

十四、Importer / Distributor 也可能因為修改產品而改變角色
這件事情對 Supply Chain 很重要。
進口商（Importer）或經銷商（Distributor）原本各自有 CRA 所規定的義務，但如果它對產品進行符合 CRA 條件的 Substantial Modification，之後再把修改後的產品放到市場，CRA 對經濟營運者角色（Economic Operator Role）的判斷就可能跟原來不一樣。
所以我現在不太會把它理解成：
「Importer 永遠只是 Importer，Distributor 永遠只是 Distributor。」
比較重要的是：
它實際對產品做了什麼？
這也是為什麼我覺得 CRA 的經濟營運者責任（Economic Operator Responsibility），必須跟企業真正的商業模式（Business Model）放在一起看。
不能只看公司名稱或供應鏈上的稱呼，就直接決定 CRA Role。

十五、對 Semiconductor，我會特別關注「誰改了哪一個產品」
例如 Semiconductor Manufacturer 提供：
晶片（Chip）＋軟體開發套件（SDK）＋參考韌體（Reference Firmware）
Customer 再修改 Reference Firmware，最後整合到自己的終端產品（End Product）。
這時我自己不會只問：
「誰改了 Code？」
而是會先把兩件事情拆開。
第一個是產品邊界（Product Boundary），第二個則是經濟營運者角色（Economic Operator Role）。
因為 Semiconductor Manufacturer 提供的 Product，跟 Customer 最後 Made Available on the Market 的 End Product，可能是兩個不同的 Products with Digital Elements。
所以不能只因為 Customer 修改過 Code，就直接推論原 Semiconductor Manufacturer 的 CRA Responsibility 全部消失；反過來，也不能只要看到 Customer 修改，就直接認為 Customer 一定承擔原產品所有的 CRA Responsibility。
我覺得真正需要一起看的，是三個問題：
哪一個產品（Which Product）？
誰做了什麼修改（Who Modified What）？
誰把哪一個產品提供於市場（Who Made Which Product Available on the Market）？
把這三件事情對起來之後，CRA Responsibility 才比較容易判斷。

十六、實務上，我可能直接把 CRA 放進既有 Change Management
做到這裡，我自己反而不太想再建立一套新的「CRA Change Process」。
如果公司本來就已經有工程變更通知（Engineering Change Notice，ECN）、產品變更通知（Product Change Notice，PCN）、軟體發布流程（Software Release Process）或韌體發布審查（Firmware Release Review），我比較傾向在既有 Change Review 裡面增加一層：
CRA 資安影響評估（CRA Cybersecurity Impact Assessment）。
第一層可以先做簡單的篩選（Screening），例如確認 Intended Purpose 是否改變、Security Function 是否新增／移除／改變、Interface / Connectivity 是否增加新的連線或輸入、Attack Surface 是否擴大，以及 Cybersecurity Hazard Nature 或 Risk Level 是否發生變化。
接下來再確認 Annex I 的適用性或 Conformity Basis 是否改變、Technical Documentation 是否需要更新，以及是否需要進一步重新進行 Conformity Assessment。
如果初步判斷沒有影響，就留下評估紀錄（Assessment Record）；如果發現可能有影響，再進入 Detailed Review。
這樣我覺得比另外建立一套 CRA Change Approval，更容易真正落進 R&D 原本的產品開發與變更流程。

十七、就算最後判定 Not Substantial，我還是會留下 Evidence
這點我覺得非常重要。
假設三年後，市場監督機關（Market Surveillance Authority）問：
「為什麼 Version 3.2 沒有重新做 Conformity Assessment？」
如果公司當時有留下 Change Assessment Record，就比較能回答 Version 3.2 到底改了什麼、Intended Purpose 有沒有改、Attack Surface 有沒有變、Cybersecurity Risk 有沒有增加，以及 Annex I Conformity Basis 有沒有受到影響。
最後還可以回答最重要的一題：
為什麼我們判斷它不是重大修改（Not Substantial）？
所以即使最後答案是 Not Substantial，我自己還是會希望留下判斷理由（Rationale）。
這又回到 Day 14 一直談的 Evidence 思維。
不是只有「需要重新驗證」的產品才需要 Evidence，「為什麼判斷不需要重新驗證」本身其實也值得留下證據。

Day 17 小結｜我現在不太問「改多少」，而是問「改變了什麼」
研究 Substantial Modification 到這裡，我自己最大的理解變化，是不再把它單純理解成 Version Number 變大，或 Code 改很多。
例如 10,000 行的程式碼重構（Code Refactoring），如果 Intended Purpose、Function、Attack Surface 與 Cybersecurity Risk 都沒有實質改變，不一定就代表 Substantial Modification。
反過來說，只增加一個新的外部輸入（External Input）或網路介面（Network Interface），Code Change 可能沒有很多，但 Attack Surface 與 Cybersecurity Risk 卻可能已經完全不同。
CRA Recital 39 本身就把 Security Update、Minor Functionality Update、新增 Feature 與 Attack Surface 等不同情境放在一起討論，也讓我更傾向從風險影響（Risk Impact），而不是**變更規模（Change Size）**來理解這件事情。
所以現在看到 Product Change，我自己比較會問：
「這項變更是否改變了產品原本的資安假設（Cybersecurity Assumptions）？」
如果 Intended Purpose、Cybersecurity Hazard、Cybersecurity Risk 或 Annex I Conformity Basis 受到影響，就值得進一步評估。
而 European Commission 在 2026 年 7 月 27 日發布的第一批 CRA Guidance，也已經把 Substantial Modification 列為重點說明議題，並透過實務案例（Practical Examples）、使用情境（Use Cases）及流程圖（Flowcharts）等方式，協助企業理解 CRA 的實際適用。
這也讓我覺得，未來 CRA 導入後，Substantial Modification 不應該只是 Compliance Team 在產品上市之後才問的一個問題。
比較好的方式可能是：
讓它真正進入產品變更管理（Product Change Management）。
每次 Product Change 時，就順手問一次：
「這項變更對 Cybersecurity Risk 與 CRA Conformity 有沒有影響？」
這樣可能比產品全部改完之後，才回頭問「要不要重新做 CRA」，實際得多。
以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流，並不是對個別產品是否構成 Substantial Modification 的正式法律判定。實際仍應依產品特性、變更內容、CRA 正式條文及 European Commission 最新 Guidance 個別評估。

Day 18 預告｜Manufacturer 之外還有誰？Importer、Distributor、AR 在 CRA 到底做什麼？
前面 17 天，我們幾乎一直站在製造商（Manufacturer）的角度看 CRA。
但做到 Supply Chain 與 CE 之後，另一個問題就開始變得很實際。
假設 Manufacturer 根本不在 EU，而產品是透過歐洲 Distributor 銷售，那麼誰才是進口商（Importer）？Distributor 又負責什麼？非 EU Manufacturer 一定需要**授權代表（Authorised Representative，AR）嗎？
AR 是不是代表可以「把 CRA Responsibility 外包給歐洲代理人」？
如果 Distributor 發現 Product 沒有 CE，還可以繼續銷售嗎？如果 Importer 發現 Product 可能不符合 CRA，又應該做什麼？
對亞洲 Manufacturer，我覺得還有一題特別實際：
公司在歐洲有子公司，它就自然是 CRA Importer 或 AR 嗎？
我目前的理解是，這些角色不能只看「集團組織圖」，也不能因為「我們在歐洲有 Office」就直接決定。
還是要回到幾個真正重要的問題：
誰製造（Who Manufactures）？誰進口（Who Imports）？誰在 EU Market 提供產品（Who Makes the Product Available on the EU Market）？誰取得正式授權（Who Holds the Formal Mandate）？
Day 18，我們就來聊 CRA 的經濟營運者（Economic Operators）：Manufacturer、Importer、Distributor 與 Authorised Representative，以及我自己在做 CRA 時，會怎麼把產品流（Product Flow）、商業流（Commercial Flow）、法律實體（Legal Entity）與 CRA 責任（CRA Responsibility）**真正對起來。